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In general, the present invention promotes the sharing of a limited resource, such as 
bandwidth, buffer space, memory space, storage, or processor time, in a competitive 
environment. This environment ensures that whomever need the most resource and has the 
ability to pay will get a share of the resource in accordance with willingness to pay. In 
5 addition, the invention adjusts for the changing needs of the participants over time. 

Advantages of the invention will be set forth in part in the description which follows 
and in part will be apparent from the description or may be learned by practice of the 
invention. The objects and advantages of the invention will be realized and attained by 
means of the elements and combinations particularly pointed out in the appended claims and 
10 equivalents. 

Brief Description of the Drawings 

Fig. 1 is a block diagram of an embodiment of the present invention. 

Fig. 2 is a flow chart of a method performed by a resource agent of Fig. 1. 
15 Fig. 3 is a flow chart of a method performed by a of Fig. 1. 

Fig. 4 is a flow chart of a method performed by a seller agent of Fig. 1. 

Fig. 5 is a chart showing an example of the result of an allocation rule. 

Figs. 6(a) and 6(b) show an example of a valuation rule. 

Fig. 7(a) and 7(b) show an example of a strategy rule. 
20 Fig. 8 shows an example of a flow chart used by an accounting system of an 

embodiment of the invention. 

Fig. 9(a) is a more detailed block diagram of the embodiment of Fig. 1. 

Fig. 9(b) shows an example of how a bandwidth resource is given to the winning 

bidder. 

25 Fig. 10 shows an example of an embodiment of the present invention including a 

"garage" for player agents. 

Figs. 1 l(a)-l 1(b) are an example of an XML file for a generic player agent. 

Figs. 12(a)-12(c) shown an example of Java code implementing a strategy rule for a 

30 Figs. 13(a)-13(c) show an example of Java code implementing an allocation rule for 

a resource agent 104. 

Fig. 14 is an example of an XML file for a generic resource agent. 

Figs. 15(a)-U ; shew examples of user interfaces for buyer and seller agents. 
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Detailed Description of Embodiments 

Reference will now be made in detail to several embodiments of the present 
invention, examples of which are illustrated in the accompanying drawings. Wherever 
5 practicable, the same reference numbers will be used throughout the drawings to refer to the 
same or like parts. 

The present invention uses distributed, self^ptimizing software agents to perform 
resource allocation more efficiently than centralized or human-based systems. 

Fig. 1 is a block diagram of an embodiment of the present invention. Fig. 1 includes 

10 a software player agent 102, which represents multiple and seller agents. A typical system 
will, include both buyer and seller agents 102. Fig. 1 also includes a software resource 
agent 104, a software accounting agent 106, a network control and management agent 108 
and a resource 110. It is contemplated that resource 110 can be a number of different 
resources, including but not limited to: bandwidth, buffer space, memory space, storage, or 

15 processor time. As shown in Fig. 1, each player agent (buyer and seller agent) can contain a 
Graphical User Interface (GUI) 122, one or more valuation rules 124, one or more strategy 
rules 126, and one or more allocation rules 128. The resource agent 104 also contains the 
same one or more allocation rules 128. 

s 102 place bids to the resource agent 104, which ultimately decides which of the 

20 player agents is awarded a portion of each resource for a predetermined amount of time. 

Resource agent 104 also controls resource 110, based on the results of the bidding, 
by sending an allocation command to network control and management agent 108. Thus, 
for example, if the resource is Internet bandwidth, if buyer A has won X Mbs of bandwidth 
for 5 minutes, resource agent 104 directs the network control and management agent 108 to 

25 give precedence to packets originating at buyer A for the next five minutes or to ensure that 
the agreed upon bandwidth requirements are met for buyer A's packets for the next five 
minutes. The mechanism used to communicate the allocation command from resource 
agent 104 to agent 108 can be any appropriate mechanism. In the example shown, the 
allocation command will include an identification of the winning buyer or buyers and an 

30 identification of the amount of resource allocated and the time period for which it is 

allocated. Other appropriate formats can be used without departing from the spirit of the 
invention. In some embodiments, agents 104 and 108 are separate agents (as shown in the 
• jx .;) other embodiments, their functions are merged into a single agent. Agents 104 
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and 108 can be owned and/or controlled by the same entity or by different entities. For 
example the owner of resource 110 could outsource the market-based allocation to a 
business partner operating resource agent 104, while keeping the network management and 
control function in its own hands, by retaining operation of the network control and 
5 management agent 108 themselves. 

In the embodiment shown, network control and management agent 108 controls 
resource 110 to implement the allocation command received from resource agent 104. 
Thus, agent 108 commits the resource allocated to a player after the resource agent 104 has 
closed the bidding. Network control and management agent 108 provides a common 

10 interface for resource agent 104 for all systems supported. In certain embodiments, there is 
one agent 108 per resource. Alternately, a single agent can control multiple resources and 
communicate with multiple resource agents 104. In the embodiment shown, network 
management and control agent 108 controls resources belonging to other entities (i.e., not to 
the owner of resource agent 104). In other embodiments, resource 110 migjit also be under 

15 the direct control of the owner of resource agent 1 04. 

Fig, 1 shows that network control and management agent 108 sends either Simple 
Network Management Protocol (SNMP) commands or COPS (Common Open Policy 
Service Protocol) commands to the resource. The SNMP protocol is well known and is 
described in RFC 1089, RFC 1270, RFC 1303, RFC 1298, RFC 1418, and RFC 1419, 
20 which are incorporated herein by reference in their entirety. The COPS protocol is well 
known and is described in 'The COPS (Common Open Policy Service," dated March 5, 
1999, available from Adobe Systems, Inc. of San Jose, CA, and RFC 2748., both of which 
are incorporated herein by reference in their entirety. Other appropriate resource control 
protocols can be used without departing from the spirit of the invention. 

25 Once one or more winning buyers are determined, resource agent 104 alerts 

accounting agent 106, which keeps track of the winning buyers, as described below in 
connection with Fig. 9(a). Accounting agent 106 provides a common interface for all 
accounting systems supported. Agent 106 preferably contains a database handier for each 
system it supports. Although accounting agent 106is shown as using one or more of the 

30 IHN and SQL database interfaces, any appropriate interface to an accounting database could 
be used. 

5 
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The 102 operates in accordance with one or more strategy rules for that agent. A 
strategy rule tells the what strategy to use in bidding against other agents for particular 
resources and, therefore constitutes a bidding mechanism for agents. 

The s also operate in accordance with valuation rules that tell the how to value a 
5 particular resource when bidding (this value is often used as a part of the strategy rule). 
Thus, a valuation rule typically tells an agent how to value each unit of a resource over a 
range of possible quantities, at a given time. Seller agents also contain their own strategy 
and valuation rules, which allow them to decide how much of a resource to offer and how to 
determine a minimum price for the resource. Strategy and valuation can depend on external 

10 information, such as accounting information and network congestion. 

The valuation and strategy of player agents (buyer and sellers) and resource agents 
are aware of a global allocation rule used by the resource agent to allocate a resource 
between the buyers. In the buyer and seller agents, this allocation rule is often considered in 
determining valuation and/or strategy. Thus, an allocation rule typically can be thought of as 

15 corresponding to a market mechanism. Examples of allocation rules include English 

auctions (familiar to persons who frequent human-based antique and estate sale auctions), 
Reverse Price Auctions (such as the main eBay model), Dutch auctions, and continuous bid- 
ask trading. Examples of allocation rules are found, for example, in 1) J.F. Rosenschein 
and G. Zlotkin, "Rules of Encounter " MIT Press 1994; 2) PhD thesis of N. Semret, 

20 "Market Mechanisms for Network Resource Sharing," Dept. of Electrical Engineering, 

Columbia University, submitted approximately May 1999; and 3) H.R. Varian, "Economic 
Mechanism Design for Computerized Agents," USENIX Workshop on Electronic 
Commerce, July 1995. Each of these three references is incorporated herein in its entirety. 
Fig. 2 is a flow chart of a method performed by resource agent 104 of Fig. 1. In at 

25 least certain embodiments, there is more than one resource agent - one for each resource. 
For example, if an ISP offers several different bandwidths, each bandwidth might be 
considered a separate resource, controlled by a separate resource agent 104. Resource 
agents preferably run within servers that can be distributed over a network. Alternately, one 
or more resource managers 104 can reside on the same system. 

30 As shown in Fig. 2, resource agent 104 receives 202 one or more bids for resource 

110 from one or more s 102. Such bids will usually include at least quantity and price 
values. If a buyer is outbid, the resource agent notifies 204 the buyer, unless the trading 
period is over 206. Once the trading period is over, the resource agent notice ?08 the 
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winning or agents and proceeds to send an allocation command 210 to network control and 
management agent 108 that will cause agent 108 to control the resource in accordance with 
the winning bids. 

Fig. 3 is a flow chart of a method performed by player/buyer 102 agent of Fig. 1. 
5 First, the is apprised of potential resources available for bidding. This is accomplished 
either by the player requesting current resource auction information from a centralized 
directory service (not shown) or by the player registering with the resource agent and 
periodically being sent hiformation about current bidding. With a directory service, a player 
agent 102 queries the directory service to find the location (e.g., in the form of a URL) of 

10 resource agents 104, garages (see Fig. 10), and other player agents 102. The decides 302 
whether to bid on a particular unit or resource 1 10 and sends 304 a bid to the resource agent. 
If the receives a notice that he has been outbid, control returns to element 302 and the agent 
decides whether to continue bidding. 

In element 302., the uses its knowledge of the system market allocation rule and of 

15 its own valuation rules to detennine how much it is willing to pay for resources at a given 
time and uses its own strategy rules to determine whether to bid on available resources. If 
the includes a GUI, a human being can visualize the market using various known graphs, 
charts or similar graphics. A user can also use the GUI to change the strategy and valuation 
rules used by the agent. 

20 It should be noted that certain embodiments include a special type of player/, called 

a broker agent, which buys resources with the intent of reselling those resources.. Thus, for 
example, a broker agent has no user for the resource (such as bandwidth) itself, since the 
broker is not an ISP or similar entity hi need of bandwidth. Instead, the broker arranges for 
third party customers, such as ISPs, to receive the benefit of the resources the broker has bid 

25 for and won, by reselling them through another resource agent instance, and the broker 
keeps the difference between the buying and selling price.. In such a case, the new 
resource agent 104 informs the network control and management agent 108 which party is 
to benefit from the resource bid for by the broker. Fig. 4 is a flow chart of a method 
performed by a player/seller 102 agent of Fig. 1. A seller agent first notifies 402 the 

30 resource agent that it has one or more units of a resource to sell (for example, IMbs for 5 
minutes or 10 minutes of processor time). Once the bidding is over, seller agent 102 will 
receive from resource agent 104 a notification 404 of the winning bidder or bidders. In at 
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least one embodiment, the seller agents collect the payments from the buyers based on 
accounting information retrieved from the accounting agent. 106. 

Fig. 5 is a chart showing an example of the result of a Progressive Second Price 
Auction (PSP) allocation rule. Other allocation rule types, as discussed above, can also be 
5 used, as specified by the particular allocation market strategy implemented in a particular 
system. Fig. 5 shows how resources are allocated and prices set once the bidding is over 
and it is determined that there are not enough resources to satisfy all the bidders. 

In the PSP auction of Fig. 5, bidder A bids $3 for 50 resource units; bidder B bids $2 
for 30 resource units; bidder C bids $1 for 30 resource units; and bidder D bids $0.50 for 20 
10 resource units. At the close of bidding, resource agent 104 allocates the resources as 
follows: The 100 available resource units are apportioned between the bidders until the 
resource is gone. Thus, the high bidder A is allocated all of the resource that he wants, as is 
the second high bidder B. Bidder C only gets 20 or the 30 resource units that he wanted and 
bidder D gets nothing, since there are no more resource units to allocate after partially 
1 5 fulfilling bidder C's wants. 

The resource agent 104 determines the amount that the bidders in the PSP auction 
are charged as follows: For each bidder, the resource agent determines the value of the 
bidder's resource if that bidder had not participated, and charges the bidder a price based on 
this determination. 

20 Thus, if bidder A had not participated, his 50 units would have been allocated as 

follows: 

10 units to bidder C (to make up C's shortfall) 
20 units to bidder D (to give D his requested number of units) 
The remaining 20 of bidder A's units would not have been allocated. 
25 The cost to bidder A is determined as follows: 

The cost of a resource unit to bidder C is $1/30. 

Thus, the value that would have been given to bidder C: 10 x ($1/30) = $0.33 



The cost of a resource unit to bidder D is $0.50/20. 
30 Thus, the value that would have been given to bidder D: 20 x ($0.50/20) = 

$0.50 



8 
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Thus, the cost of A's resources had A not participated is $0.33 + $0.50 =* $0.83. 
Bidder A is charged this amount for his 50 units of resource. 

Similarly, if bidder B were not present, his 30 units would have been allocated as 
follows: 

5 10 units to bidder C (to make up C's shortfall) 

20 units to bidder D (to give D his requested number of units) 

The cost to bidder B is determined as follows: 

10 The cost of a resource unit to bidder C is $1/30. 

Thus, the value that would have been given to bidder C: 10 x ($1/30) = $0.33 

The cost of a resource unit to bidder D is $0.50/20. 

Thus, the value that would have been given to bidder D: 20 x ($0.50/20) = 

15 $0.50 

Thus, the cost of B's resources had B not participated is $0.33 +- $0.50 = $0.83. 
Bidder B is charged this amount for his 30 units of resource. 

20 Similarly, if bidder C were not present, his 20 units would have been allocated as 

follows: 

20 units to bidder D (to give D his requested number of units) 
The cost to bidder C is determined as follows: 

Value that would have been given to bidder D: 20 x ($0.50/20) = $0.50 

25 

Thus, the cost of C's resources had C not participated is $0.50. Bidder C is charged 
this amount for his 20 units of resource. 

It should be noted that Fig. 5 shows only how resources are allocated after bidding is 
closed. An allocation rule also includes within it rules or explanations of how the auction 
30 itself should be conducted. For example, a PSP auction generally lasts for a predetermined 
amount of time (for example, five minutes). While the bidding is open, resource agent 104 
collects all bids received from the s 102 and saves them in a bidlist data structure (e.g., a 
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linked list). The bidlist data structure indicates which bid is the most recent bid for each 
102. 

As bids are received from the s 102 by the resource agent 104, the resource agent 
104 transmits the bids received to the other agents 102, so that all agents know what all 
5 other participating agents are bidding. Because each 102 has knowledge of the allocation 
method, each 102 can apply its strategy and valuation rules to determine whether that agent 
is going to be allocated the resources on which it has bid The agent, applying the 
allocation, strategy, and valuation rules, determines whether it should bid again. In a PSP 
auction, bidding usually stabilizes after a few minutes. In some embodiments, resource 

10 agent 1 04 does not hold the auction open for a predetermined time, but instead waits a 
predetermined amount of time after the bidding has stabilized to make sure that no other 
bids are received. In some cases, resource agent 104 announces to the s 102 that bidding 
will close in a certain number of minutes or seconds. In some cases, if a bid is received 
during this time period, the auction is kept open a bit longer. 

15 Thus, an allocation rule (known to all agents) also includes information about how 

the auction will be conducted by resource agent 104, including, for example: how long an 
auction will last, if the auction has no set time period, what are the conditions for the 
auction to close. In addition, as described above, the allocation rule includes rules 
describing how price and quantities are assigned after the auction has closed. 

20 In a preferred embodiment of the invention, auctions last 5 minutes, although other 

periods of time could be used and these periods of time could be either variable or user- 
settable. In a preferred embodiment, the bandwidth resource being auctioned during a 
current auction is allocated immediately and another auction is begun immediately. Thus, 
an auction occurs roughly every five minutes for the bandwidth that will be used by the 

25 buyers during the next five minutes. Other embodiments may not auction all bandwidth for 
immediate use. 

The PSP auction model is described further in A. A. Lazar and N. Semret, "Design 
and Analysis of the Progressive Second Price Auction for Network Bandwidth Sharing," 
Telecommunications Systems, Special issue on Network Economics, which is attached 
30 hereto as Appendix A and forms a part of this application. 

Other examples of allocation rules include, but are not limited to a Hold Option 
Auctions, which are discussed, for example, in the PhD thesis of N. Semret, "Market 
Mech misms for Network Resource Sharing," Dept. of Electrical Engineering, Columbia 

10 
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University, submitted approximately May 1999, Chapter 4 of which (28 pages) is attached 
hereto as Appendix B and which forms a part of this specification. The Hold Option is a 
concept for advance price and quantity guaranteed reservations of network resources in a 
real-time market environment. Periodic auctions (progressive second price, or other) among 
5 arrivals grouped in batches give rise to the spot market of capacity changes. A reservation 
guaranteeing access for an arbitrary duration with a capacity piece below the bid can be 
made at any time before or during service. This eliminates the risk (which is inherent on the 
spot market) of losing resources to higher bidders before service completion. The 
reservation is defined as ahold option, and is analogous to derivative financial instruments 

10 such as options and futures integrated over time. Based on a heavy traffic diffusion model, 
reservation fees can be computed as the fair market price of a hold option. In at least one 
embodiment, special player agents 102 are allowed to place such hold options, thus 
providing a guaranteed reservation of a network resource for an arbitrary duration. 

Figs. 6(a) and 6(b) show examples of valuation rules. In Fig. 6(a), a valuation rale is 

1 5 formed of pairs of quantity /price values. In Fig. 6(b), a valuation rule is formed as a 
function of various input variables. These input variables can include any or (but are not 
limited to): the number of hits on a web site ; the average file size downloaded (and the 
bandwidth needed to service those files); the expected delay or expected latency, and the 
value of each hit. Valuation can also be time dependent (e.g., higher valuations are assigned 

20 during peak usage times when more bandwidth is needed) and the network state (e.g., more 
bandwidth is needed if the network is congested). 

It should be noted that there are engineering tradeoffs for the type of valuation rule 
used. Because a low-level valuation rule requires more inputs, which require more time and 
effort to collect and receive, a low-level description may require a large amount of data to 

25 be transferred in order for the agent to be able to bid in accordance with the low-level 

valuation rule. On the other hand, a simple, high-level valuation rule reduces the ability of 
an agent to make an optimum bid because the agent is operating with less information. 
Either implementation can be correct for a given circumstance, depending on the needs of 
the particular player agent and the limitations of its system and network. 

30 Figs. 7(a) and 7(b) shows examples of strategy rules. Fig 7(a) shows a s imple rule 

set, where the first precedent is to identify the type of allocation system being used. Once 
the allocation system i f identified, the 102 applies a set of predefined conventk il rules to 
determine whether it should bid (or bid again). Fig. 7(b) shows an example v f ^ the 

11 
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strategy is based on a user-defined function. Li the example, if the function reaches a 
threshold value, the agent 102 will bid (or bid again). Other examples of strategy rules 
decide not just whether the agent should bid, but how much the agent should bid, in 
accordance with the allocation rule being used by the system and in accordance with factors 
5 specific to that agent (such as, for example, those factors discussed above in relation to 
valuation rules). 

Certain strategy rules are very simple and involve bidding constant amount. Such 
simple strategy rules may result in uneven amounts of bandwidth being won. Another 
example strategy rule is periodic bidding, in which a buyer agent enters auctions 
10 periodically. 

Fig. 8 shows an example of a flow chart used by an accounting system of an 
embodiment of the invention. The accounting system is notified whenever a resource agent 
closing bidding on a resource unit and keeps track 802 of the winning bids and resulting 
allocations. Periodically, the accounting system bills 804 the seller a percentage of the 

15 resources sold, which is received by the owner of the resource agent for operating the 
resource agent and account agents of the Merkato platform. 

Fig. 9(a) is a more detailed block diagram of the embodiment of Fig. L It will be 
understood that Fig. 9(a) details only one possible way to implement the present invention 
and that the description herein is not to be taken in a lhniting way with regard to operating 

20 systems, protocols, programming languages, etc. The example shown is implemented in , 
Java using the World Wide Web, but the invention is not limited to such a system. In fact, 
the invention can be implemented on any appropriate computers and networks, using any 
appropriate programming language, hardware, software, and operating system. Parts of the 
system can be implemented in software, firmware, or hardware, as needed. 

25 Fig. 9(a) includes four layers: an operating system (OS) layer 902, a Java layer 904, 

a Merkato layer 906, and a diffex layer 108. In the described embodiment, the OS layer 902 
and the Java layer 904 are conventional and will not be described herein. Other 
embodiments may make changes to one or more of layers 902 and 904 to enhance the 
performance of the system, for example. In this example, the use of Java layer 904 makes 

30 the system platform independent. Thus, the Merkato layer 906 can run on any computer or 
computing device (such as a wireless device , pager, cell phone, or Internet appliance) 

Layer 906 allows a player agent 102 to be executed on the client side, from a Java 
application or an applet executing in a Web browser. , \fewtely (or in addition), a player 
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agent 102 can be executed as a servlet on a web server, which is the "garage" environment 
of Fig. 10. 

Layer 908 enables real-time resource markets between peering ISPs. The layer 908 
allows ISPs to buy and sell resources, such as bandwidth, from each other in real-time. 
5 Layer 908 auctions in real-time the outgoing bandwidth on each ISP's line out of the 

exchange, ensuing that at all times, the bandwidth goes to the buyer with the highest value 
for it. Layer 908 also allows for buying and selling in advance (i.e., making reservations 
with guaranteed capacity and capped prices) through a derivative market of options, in 
effect enabling the trading of risk and hedging, for original ISP buyers and sellers, as well 

10 as for purely financial players. 

Fig. 9(b) shows and example of how a winning buyer ISP 952 is given a resource, 
such as bandwidth. In Fig 9(b), a seller ISP 956 has a seller 902 agent running on a diffex 
client. As discussed above, the seller agent determines that the ISP has bandwidth to sell 
(e.g., through user input via the seller agent GUI) and makes that bandwidth available for 

15 auction by sending a message to resource agent 904 (see numeral 1 in a circle). The buyer 
ISPs 952, 954 have s 902 running on a diffex client. The s bid on the bandwidth in 
accordance with their allocation rules, strategy rules, and valuation rules, as discussed above 
(see numeral 2 in a circle). For certain types of allocation models, the agents also receive 
information about bids during the auction (not shown). Once the auction is concluded, 

20 resource agent 904 sends an allocation command to network control and management agent 
908 (numeral 3 in a circle), which in turn controls a router 970 of the seller ISP so that the 
winning buyer ISP receives its bandwidth (see numeral 4 in a circle). 

Resource agent 104 in layer 908 interfaces with the resource (e.g., with the router 
970 of the seller ISP) to allocate the bandwidth to the winning bidder. Specifically, 

25 resource agent 904 interfaces with control agent 908 to send commands to the router of the 
seller ISPs. If, for example, the resource is bandwidth, allocation to the winning bidder can 
be effected by one of the following or by any other appropriate method: 

a) the router 970 is given a set of class-based weighted-fair queuing 
parameters to be used by the router to control packet queuing in the router so that the 

30 winning ISP buyers are assured of receiving the bandwidth which they was allocated by the 
resource agent. These queuing parameters will give priority to the winning bidders when 
packets from the winning ISPs are sent to the seller ISP's router. 
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b) the router is given a set of committed access-rate parameters to be used by 
the router to limit and shape traffic assure each buyer the bandwidth which it is 
allocated, or 

c) capacity within an MPLS (Multiprotocol Label Switching) tunnel 
5 between two points in the seller's network. 

Thus, as shown in Fig. 9(b), packets 960 from the winning buyer ISP(s) are routed through 
the seller's router and on to the seller ISP's network 956, from which they are delivered to 
their destination. In at least one embodiment, the winning ISPs are aware that they have 
won and use existing routing protocols to ensure that they direct packet traffic to the seller 

10 ISP's router. In other embodiments, the resource agent informs routers in the winning ISPs 
of the needed routing change using known routing protocols. 

in the described embodiment, the resource agent is always executed on a Web 
server. Each resource agent 104 runs as a servlet on a Web server. This architecture is 
scalable because resource agents 104 can be distributed to run on any Web servers 

15 supporting the concept of a servlet. 

In the described embodiment, communications between a player agent (either a 
buyer or a seller) 102 and a resource agent 104 are performed via a resource agent proxy 
using any of http extensions, native TCP protocol, or Java's remote method invocation 
(rmi). All communications are secured through an appropriate mechanism such as the 

20 secured socket layer (SSL). A shown in Fig. 9(a), each agent (player and resource) has an 
allocation rule object 128. The player agents 102 also have valuation rule objects 124, 
strategy rule objects, 126, and a GUI object 122. In addition, the resource agents 104 have 
networking and accounting drivers for interfacing with external support systems. Further 
security is provided through the implementation of specific allocation rules that protect the 

25 stability of the system. Specifically, each user is required to pay a bid fee to resource agent 
104 for every bid sent. The implementation of a bid fee is intended to prevent users from 
trying to artificially destabilize the resource price and to prevent a "man in the middle" 
attack, which is defined as a third party intercepting a bid from another agent and keeping 
sending the same bid over and over. In addition, timestamps are preferably used to 

30 discriminate every bid. Thus, if a bid has a previously used timestamp, resource agent 104 
will ignore that bid. 

In the described embodiment, communication between agents is effected using http, 
thus bypassing many problems associated with firewalls, proxies, and other middleware. 
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Fig. 10 shows an example of an embodiment of the present invention including a 
"garage" for player agents 102\ The garage 130 is a component on a web server that serves 
the purpose of storing agents and enabling their execution remotely from a user's computer. 
The garage contains an "attendant" program 131 whose job is to help mobile agents find a 
5 parking place in the garage and to ensure proper agent execution when the agents want to 
run autonomously. Garage 130 performs the function of a distributed database to store the 
agents 102' and provides a distributed processor (not shown) to execute the agents. Garage 
130 can be located on the same system as resource agent 104, but can also be located on a 
different machine. 

1 0 The attendant is an example of a multi-agent. Multi agents coordinate multiple 

simple agents to act together. Multi-agents can be used to form coalitions of agents, using 
the attendant to bid for aggregated resources on behalf of the coalition. In the described 
embodiment, the agents communicate with the attendant to let the attendant know that they 
need resources. The multi-agent aggregates the various types of resources requested (e.g., 

1 5 different connection speeds or different bandwidths) and uses the allocation rule and its own 
strategy and valuation rules to bid on behalf of the agents. If the multi-agent wins, the 
resource is divided between the agents and the attendant so informs the resource agent 104, 
which allocates the bandwidth accordingly. A broker is an example of a multiagent, 
coordinating buyer and seller agents for a common objective to act as a profit-maximizing 

20 reseller. 

In the described embodiment, agent mobility to the garage is provided through 
XML. The syntax and semantics of an agent is described using XML. For example, the 
semantics of an agent can include its allocation, strategy and valuation rules. Each agent 
can be transferred to the "garage" 130 by generating its XML description. Once an agent is 

25 provided in this form, it can be re-instantiated either in a garage 130 or in a user's computer 
in an applet or a java application. 

Figs. 1 l(a)-l 1(b) are an example of an XML file for a generic player agent 102. 
This XML would be used, for example, to send the agent 102 to a client for execution in 
garage 930. Each of the XML tags (indicated by o brackets) identifies an attribute of the 

30 agent that is to be activated in the garage. It will be understood that the XML of Fig. 1 1 is 
shown for purposes of example only and that other embodiments of the invention may use 
more or fewer tags and/or different tags than those shown in Fig. 1 1 . 
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Figs. 12(a)-12(c) shows an example of Java code implementing a strategy rule for a 
102. This example implements a strategy in accordance with the PSP auction model 
described above. As shown in section 1234 of Fig. 12(c), an agent using this strategy will 
submit a new bid only if the new bid determined in the rule is increased by at least a 
5 calculated value epsilon. Note that this strategy rule calls a valuation rule in line 1232 of 
Fig. 12(c). This valuation rule implements a PSP valuation method. 

Figs. 13(a)-13(c) show an example of Java code implementing an allocation rule for 
a resource agent 104. This example looks at a number of received bids in a bidlist data 
structure and computes an allocation (similar to that of Fig. 5) given the current bids on the 

1 0 bid list in accordance with a PSP auction allocation model. 

Fig. 14 is an example of an XML file for a generic resource agent 104. This XML 
would be used, for example, to send the resource agent 104 to a web server. Each of the 
XML tags (indicated by o brackets) identifies an attribute of the agent that is to be 
activated on the server side. 

15 Figs. 15(a)-15(r) show examples of user interfaces for buyer and seller agents. Figs. 

15(a) and 15(b) show an example of an html GUIs that provides static information to a user. 
Figs. 15(c) and 15(d) show an example of GUIs implemented as a Java applet. The 
information provided by these interfaces is continuously updated in real-time or 
periodically. Figs. 15(e)-t5(r) show an example of an advanced GUI, which is preferably 

20 also implemented as an agent. Particular buyer and seller agents may have one, none, or all 
of the particular GUIs shown here, or may have GUIs providing other relevant information 
not shown here. Note that several of these GUIs allow a human user to choose the valuation 
and/or strategy rules and to determine when and how to bid. It should be understood that in 
the preferred embodiment, buyer agents are capable of bidding on their own. Other 

25 embodiments may contain agents that bid only at the direction human beings. 

Accordingly, the present invention is intended to embrace all such alternatives, 
modifications and variations as fall within the spirit and scope of the appended claims and 
equivalents. 
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What is claimed is: 

1. A method for real-time market-based resource allocation, comprising: 

receiving at least one bid in real-time for a resource; 
5 deciding which of the at least one bids has won the bidding; and 

controlling the resource so that it is committed to the winning bidder. 

2. The method of claim 1, wherein the resource is bandwidth. 
10 3. The method of claim 1, wherein the resource is buffer space. 

4. The method of claim 1, wherein the resource is processor time. 

5. The method of claim 1, wherein the resource is controlled in real-time so that the 
15 winning bidder has access to the resource he has won as soon as bidding closes. 

6. The method of claim 1, wherein the bid is received from a software agent. 

7. The method of claim 6, wherein the software agent bids in accordance with a 
20 strategy rule. 

8. The method of claim 7, wherein the strategy rule is a truthful best reply strategy. 

9. The method of claim 6 3 wherein the software agent bids in accordance with a 
25 valuation rule. 

10. The method of claim 9, wherein the valuation rule is determined in accordance 
with at least one measured network parameter. 

30 11. The method of claim 6, wherein the software agent bids in accordance with an 

allocation rale. 



78 

SUBSTITUTE SHEET (RULE 26) 



WO 01/88811 



PCT/US01/15424 



12. The method of claim 1, wherein deciding which bid has won the bidding is 
performed in accordance with an allocation rule. 

13. The method of claim 12, wherein deciding which bid has won the bidding is 

5 performed in accordance with a market allocation rale also used by a buyer software agent, 
the market allocation rule defining the rules of the resource market. 

14. The method of claim 12, wherein deciding which bid has won the bidding is 
performed in accordance with an English Auction market allocation rule. 

10 

15. The method of claim 12, wherein deciding which bid has won the bidding is 
performed in accordance with a continuous bid-ask trading market allocation rule. 

16. The method of claim 12, where deciding which bid has won the bidding is 
15 performed in accordance with a progressive second price auction allocation rule. 

17. The method of claim 12, where deciding which bid has won the bidding is 
performed in accordance with a hold option allocation rule. 

20 18, The method of claim 1 , further comprising: 

storing information concerning which bid has won, for accounting purposes. 

19. The method of claim 1, wherein there are several resources, and a respective 
resource agent performs the elements of claim A for each resource. 

25 

20. The method of claim 1, wherein there is one resource, and a single resource 
agent performs the elements of claim 1 for the resource. 

21 . The method of claim 1 , wherein th e elements of claim 1 are performed by a 
30 resource agent executing on a separate computer than the placing the bids. 
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22. The method of claim 1, wherein the elements of claim 1 are performed by a 
resource agent executing on the same computer as at least one placing at least one of the 
bids. 

5 23. The method of claim 1, wherein the is controlled by a human being, who 

decides how to bid. 

24. The method of claim 1, further comprising: 

deciding, by a bidder agent, how to bid based on a valuation function of the 
10 bidder agent and a strategy algorithm of the. 

25. The method of claim 1, further comprising: receiving an offer to sell resources 
from a seller agent. 

15 26. The method of claim 1, further comprising: 

receiving player agents in a garage of a resource agent and receiving bids 
from player agents in the garage. 

27. The method of claim 1, wherein the bid is received from a player agent that also 
20 submits offers to sell resources. 

28. The method of claim 1, further comprising: 

before bidding, receiving a request from a buyer software agent for a location 
of resource agent. 

25 

29. The method of claim 1, further comprising: 

sending at least one bid in real-time for a resource; 
receiving a notification that the sent bid has won the bidding; 
selling the use of the winning resource to third parties through a separate 
30 resource agent; and 

notifying a resource management and control agent that the third parties will 
be using the resource. 
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30. A method, performed by a multiagent, comprising: 

sending at least one bid in real-time for a resource in accordance with a 
strategy rule and a valuation rule of the multiagent and in accordance with a system- 
wide allocation rule; 
5 receiving a notification that the sent bid has won the bidding; 

selling the use of the winning resource to third parties through a separate 
resource agent; and 

notifying a resource management and control agent that the third parties will 
be using the resource. 

10 

31. A method, performed by a buyer agent, comprising: 

sending at least one bid in real-time for a resource in accordance with a 
strategy rule and a valuation rule of the buyer agent and in accordance with a system-wide 
15 allocation rule; 

receiving a notification that the sent bid has won the bidding; and 
making use of the resource in real time, immediately after winning the bid. 



32. The method of claim 32, wherein the system wide-allocation rule is aPSP 
20 allocation rule. 



33. A system for real-time market-based resource allocation, comprising: 
means for receiving at least one bid in real-time for a resource; 
means for deciding which of the at least one bids has won the bidding; and 
25 means for controlling the resource so that it is committed to the winning 

bidder. 



34. A system for real-time market-based resource bidding by a multiagent, 
comprising: 

30 means for sending at least one bid in real-time for a resource in accordance 

with a strategy rule and a valuation rule of the multiagent and in accordance with a 
system-wide alloc, ; on rule; 

means for : : : ivirig a notification that the sent bid has won the bidding; 
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means for selling the use of the winning resource to third parties through a 
separate resource agent; and 

means for notifying a resource management and control agent that the third 
parties will be using the resource. 

5 

35. A system for real-time market-based resource bidding by a buyer agent, 
comprising: 

means for sending at least one bid in real-time for a resource in accordance 
with a strategy rule and a valuation rule of the buyer agent and in accordance with a system- 
10 wide allocation rule; 

means for receiving a notification that the sent bid has won the bidding; and 
means for making use of the resource in real time, immediately after winning 

the bid. 

15 36. The system of claim 35, wherein the system wide-allocation rule is a PSP 

allocation rule. 

37. A system for real-time market-based resource allocation, comprising: 

a portion configured to receive at least one bid in real-time for a resource; 
20 a portion configured to decide which of the at least one bids has won the 

bidding; and 

a portion configured to control the resource so that it is committed to the 
winning bidder. 

25 38. A system for real-time market-based resource bidding by a multiagent, 

comprising: 

a portion configured to send at least one bid in real-time for a resource in 
accordance with a strategy rule and a valuation rule of the multiagent and in 
accordance with a system-wide allocation rule; 
30 a portion configured to receive a notification that the sent bid has won the 

bidding; 

a portion configured to sell the use of the winning resource to third parties 
through, a scp-Tn.te resource agent; and 
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a portion configured to notify a resource management and control agent that 
the third parties will be using the resource. 

39. A system for real-time market-based resource bidding by a buyer agent, 
5 comprising: 

a portion configured to send at least one bid in real-time for a resource in 
accordance with a strategy rule and a valuation rule of the buyer agent and in accordance 
with a system-wide allocation rule; 

a portion configured to receive a notification that the sent bid has won the 

10 bidding; and 

a portion configured to make use of the resource in real time, immediately 
after winning the bid. 

40. The system of claim 39, wherein the system wide-allocation rule is a PSP 
15 allocation rule. 

41. A computer program product, including instructions for causing a data 
processing device to perform actions for real-time market-based resource allocation, 
comprising: 

20 receiving at least one bid in real-time for a resource; 

deciding which of the at least one bids has won the bidding; and 
controlling the resource so that it is committed to the winning bidder. 

42. A computer program product, including instructions for causing a multiagent of 
25 a data processing device to perform actions for real-time market-based resource bidding, 

comprising: 

sending at least one bid in real-time for a resource in accordance with a 
strategy rule and a valuation rule of the multiagent and in accordance with a system- 
wide allocation rule; 

30 receiving a notification that the sent bid has won the bidding; 

selling the use of the winning resource to third parties through a separate 
resource agent; and 
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notifying a resource management and control agent that the third parties will 
be using the resource. 

43. A computer program product, including instructions for causing a buyer agent 
of a data processing device to perform action for real-time market-based resource bidding, 
comprising: 

sending at least one bid in real-time for a resource in accordance with a 
strategy rule and a valuation rule of the buyer agent and in accordance with a system-wide 
allocation rule; 

receiving a notification that the sent bid has won the bidding; and 
making use of the resource in real time, immediately after winning the bid. 

44. The computer program product of claim 43, wherein the system wide-allocation 
rule is a PSP allocation rule. 
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Figure 3 
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100 units of resource: 
A bids for 50 at $3, 
B bids for 30 at $2 
C bids for 30 at $1 
D bids for 20 at $0.50 




Example Market Allocation Rule (PSP 

Figure 5 
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<?xml version="1 .0" encoding="UTF-8" ?> 
- <AuctionPlayer context="http://HOSTNAME:HTTP_PORT/bx/garage"> 
- <SingleFrameGUI> 

<TextPanel name^News" height= "50" visib!e= B true" border="false" /> 
<LoginPanel name="Login n height="160" visible="true" border="true" /> 
<ResourceAgentPanel name="ResourceAgent" height= n 80" visible="true" 
borden="true" /> 

<UploadAgentPanel name="Garage" height="80" visible="true" 
border="true7> 

<BidCanvasPanel name-'BidCanvas" height="180" visible=°false" 
border="true" /> 

- <StrategyChoicePanel name="Strategies" height="160" visible="tnie" 

borde^'true^ 

<StrategyPanel name="Manuar strategy="ManualStrategy" /> 
<StartegyPanelNotEditable name-'Auto' strategy- TruthfulStrategy" l> 
</StrategyChoicePanel> 

- <ValuationChoicePanel name="Valuations" height="240" visible="fabe" 

border="true"> 

<WebValuationPanel name=" Web Valuation" valuation="WebValuation° l> 
<ValuationPanel name=°Elastic Demand" valuation "RobertsValuation" l> 
<ValuationPanel name=°lnelastic Demand 0 valuation-LinearValuatlon" /> 
<BudgetValuationPane! name="Budget Valuation" label=" " 
valuation-'BudgetValuation" /> 
</ValuationChoicePanel> 

<PlayerlnfoPanel name= B Allocation" height= n 120" visible*"true" 
border="true"/> 

<BudgetPanel name="Budget" height="80° visible="false° border="true" /> 
<DisplayPanel name=°Units" height="80° visible-"false n border="true" l> 
<IPAddressPanel name="IP" height=°110 n visible='false" border="tnie" /> 
<ConnectionPanel name="Connection" height="140" visible="false" 
border="true" l> 

<BidTablePanel hame="Bid Table" height="400" visible="false" 
border= B true"/> 

<BidGraphPanel name="Bid Graph" height="400" visible=°false" 
border="true"/> 

<AllocationGraphPanel name="Allocation Graph" height="400 n visible="false" 
bonder="true" /> 
</SingleFrameGUI> 

<Piayerldentity name="USERNAME" passwd="PASSWD° ipaddress=1P_ADDRESS" 
netmask="NETMASK" /> 

- <LinearValuation label= 0 lnelastic Demand"> 

<Parameter name-'qmax" value="45000.0" label="Kbps D l> 
<Parameter name="vmax" value="44928.0" label="$/month fl l> 
</LinearValuatfon> 

- <RobertsValuation current="false" label-'Elastic Demand"> 

<Parameter name-'qmax" value="45000.0" label="Kbps" /> 
<Parametername="vmax" value="4928.0" label="$/month" /> 
</RobertsValuation> 

- <BudgetValuation current="true" labeN'Budge* Valuation'^ 

<Patameter name-'qmax" value="1000.0" htel-'Kbps" /> 
<Parameter name=°budget" value="100 M" ' ;el="$/month" l> 
</BudgetValuation> 
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- <WebValuation label="Web Valuation'^ 
<param name="delay" value="100.0" i> 
<param name="hitspeimonth B value="100000.0 n /> 
<param name="filesize" value-"1000.0 u /> 
<param name-'centsperhif value="0.1" /> 
<param name?"randomize" value="f alse" l> 
</WebValuation> 

Parameter name="budget" value="51840.6 n label="$/month" /> 
<ManualStrategy current="false n label-'Manual" /> 
<TruthlulStrategy current="true" lab6l=°Auto n l> 
<resourceAgentURL nickname="RESOURCE_MAME' 

cuTOnt= ,, trae l, >http://HOSTNAME:HnP_PORT/bx/l«SOURCE - NANIE</resourceAge 
<uploadURL nickname=°HOSTNAME 

garage D >http.7/HOSTNAME:HTTP_PORT/bx/garage</uploadURL> 
<param name- "playerlntervai" value="2000" /> 
<param name="timeouf value=°2000" l> 
<param name-'timelabel" value^min" /> 
<param name="currencylabel" value s "c" l> 
<param name-'quantitylabel" va!ue="Mbps" /> 
<param name-'debug" value-'false" /> 
</AuctionPlayer> 



Figure 11(b) 



SUBSTITUTE SHEET (RULE 26) 



WO 01/8881 1 



PCT/USOl/15424 



14/38 



/* 

* File: 



Truthful.java 



* 



* Remark: 



Strategy for player with diminishing returns 



*$ld:Truthful.java J v1.16 



07:43:19 cobe Exp$ 



*/ 



package ihn.merkato; 
import org.w3c.dom*; 
import com.sun.xml.tree.XmlDocument ; 

I** 

* The strategy that bids the truthful best reply as in Proposition 1 o 
f 

*the PSP paper. 

* It will only submit the bid if utility will be increased by at least 

* epsilon. 
*<p> 

*@author Nemo Semret 



7 

public class Truthful extends AuctionStrategy { 
Bid tmp = createBid( ) ; 

* Finds truthful best reply as in Proposition 1 of 
*the PSP paper. 

* Sets the bid at the player if utility will be increased by at leas 

t 

* epsilon. 
*<p> 

* If timelogging is enabled, this will write to the player's 

* log a line with current time, bid, allocation, and utility, 
*at each call. 

* @see #epsilon 

* @see ihn.merkato.AuctionPlayer#setBid 

7 

public boolean bid( ) { 

double lq=0, uq= getPlayer ( ) .getValuation ( ) ,qmax ( ) , mq= (uq+lq) / 2, 
dq= getPlayer ().dq(); 

if(debug()) { 

getPlayer ( ) Jog ("q range = [ n +lq+ 
" , n +uq+"] dq="+dq+ 
11 Q="+getPlayer (). stuff ()); 
getPlayer ().addnews ("."); 



Example of Agent Strategy 



Figure 12(a) 



SUBSTITUTE SHEET (RULE 26) 



WO 01/88811 PCT/US01/15424 

15/38 
TruthfuLtxt 

//see Proposition 1 
inti=0; 

double mp, dv; 

while ( uq-lq >dq && i<20 ) { 
i++; 

mq= (lq=uq)/2; 
/* 

if (mq < getPlayer ( ) .stuff ( ) - 

(getBidder ( ) .getBidList ( ) ) .demandAtPrice ( 

getPlayer ( ) .dval (mq, mq+dq) , 

getPlayer ().getld())) 

*/ 

/ / the following is equivalent and more general 
dv*getPlayer ( ) .getValutaion ( ) .dval (mq, mq+dq) ; 
mp=getBidder ( ) .getBidList ( ) .marketPrice (getPlayer ( ) .stuff ( ) 

-mq, 

getPlayer ().getld() 

); 

if(debug()) 

getPlayer (). log ("i="+i+" mq=°+mq+" dv="+dv+" mp="+mp) ; 

if (dv>mp) 

lq=mq ; 
else 

uq=mq ; 

} 

tmp.bidderid = getPlayer ( ) .getld ( ) ; 
tmp.price = Data.MAXPRICE; 
tmp.qty = lq; 

if(debug()) 

getPlayer (). log (""+i+" steps, q range = ("+lq 

+","+uq+"] currentbid="+ 
getBidder ( ) .anteBid ( ) + 0 found "+tmp) ; 

if(utfl(tmp) <0) { 
uq= tmp.qty ; 
lq=0; 

} 

i=0; 

while (uq-lq>dq && i<20) { 
tmp.qty = (uq+lq)/2; 
i ++ ; 

if(debug()) 

getPlayer ( ) .log ("i="+i+ M q=" + tmp.qty ) ; 
if (util (tmp) <0) 

uq= tmp.qty; 
else 

Iq = tmp.qty ; 

Example of Agent Strategy 

Figure 12 (b) 
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} 

/ / need this in case the above loop is just outside the budget 
while (util ( tmp) <0&&tmp.qty>0&&i<40) { 
i ++ ; 

tmp.qty -dq; 
if(debug()) 
getPlayer (). log 0=°+!+" q="+tmp.qty) ; 

} 

if(debug()) 

getPlayer ( ) Jog (""+i+ n steps. range=[ "+lq+ u , "+uq+° ] currentbid="+ 
1232 getBidder().anteBid().qty); 

tmp.price = getPlayer ( ) . getValuation ( ) .dval ( tmp.qty, tmp.qty+dq) ; 

double u = getPlayer ( ) .currentUtil ( ) ; 
double newu - util (tmp) ; 

if(debug()) { 
getPlayer ( ) .log ("currentalloc= n + 

getBidder ( ) .currentAllocation ( ) + 
" newbid="+tmp+" antebid=°+ 
geffiidder().antBid()); 
getPlayer ( ) .log ("u="+u+ n newu="+newu+" ante=° 
+util (getBidder ( ) .anteBid ( ) ) 
+" fee="+getBidder ( ) .bidFee ( ) 
+" epsilon="+epsilon ( ) 
+" avgdur^+gelAvgDuration ( ) ) ; 

} 

if (getPlayer(). trace ()} { 
Bid alloc = getBidder ( ) .currentAllocation ( ) ; 

getPlayer ( ) .log (" "+getBidder ( ) .anteBid ( ) .qty 

+T+getBidder ( ) .anteBid ( ) .price+T+ 
alloc.qty+T+alloc.price+T+ 
getPlayer ( ) .currentUtil ( ) ) ; 

} 

if ( newu >u + epsilonQ) { 

if (debug ( ) ) getPlayer ( ) .addnews ("*"); 
return getBidder ( ) .setBid (tmp.qty, tmp.price) ; 

} 

else { 

if (debug ()) getPlayer () .addnews ( n - n ) ; 
v return false ; 

} 

* Example of Agent Stratet v 

Figure 12 
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/* 

* BidList object 

* File: PSPBidList.java 
* 

* 
* 

* 

*l 

package ihn.diffpex; 

import ihn.merkato.Bid; 

import ihn.merkato.Data; 
I** 

* 

* 

*/ 

public class PSPBidList extends ihn.merioto.GenericBidList { 

I** 

* Compute an allocation given the current profile of opponents 

in 

* this bidlist. This class uses the Progressive-Second-Price 

* auction rule. 

* @param tb The bid for which the allocation is to be calculate 

d. 

* @param Q The total quantity of resource available. 
*/ 

public Bid allocation (Bid tb, double Q) { 
return PSPallocation (tb, Q) ; 

} 

I** 

* Cumpute an allocation given the current profile of opponents 

in 

* this bidlist, with the Progressive-Second-Price 

* auction rule. 

* @param tb The bid for which the allocation is to be calculate 

Figure (a) 
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d. 

* @param Q The total quantity of resource available. 
*/ 

private synchronized Bid PSPallocation (Bid to, double Q) { 
Bid index = top; 
Bid alioc= new Bid ( ) ; 

double leftover = Q; / /leftover with player id 
double leftoverwo =Q; / /leftover without player id 
double qAj , qAjO , num=0, den=0 ; 
boolean gotcha = false ; 

alloc.qty = Math.min (tb.qty, 

Math.max (Q-demandAtPrice (tb.price, tb.bid 

derid) , 0) ) ; 

while(index.next != null) { 
index = index.next; 

iffindex.bidderfd != tb.bidderid) { 

if (index.price <= tb.price && Igotcha) { 
leftover™ tb.qty; 
if (leftover <=0) leftovepO ; 
gotcha = true ; 

} 

qAj = (index.qty<= leftover ?index.qty: leftover); 
qAjO= (index.qty <= leftoverwo ? index.qty : leftoverwo) ; 
num += (index.price* (qAjO-qaj) ) ; 
// den += ( qAjO- qAj) ; 

leftoverwo - = index.qty; 
leftover - = index.qty ; 
if (leftover <=0) leftover=0; 
if (leftoverwo <=0) leftoverwo=0 ; 

} 



} 

1 1 if ^cha) alloc.qty = (tb.qty<= leftover ? tb.qty : 

Figure 13(b) 
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leftover) ; 

/ / alloc.price = den>0 ? num/den : 0 ; 

alloc.price = alioc.qty>0 ? num/allocqty : 0 ; 
alloc.bidderid = tb.bidderid ; 

return alloc; 

} 

jirk 

* Bids with ID#0 are not counted. 

*/ 

public double revenue (double Q) { 
Bid index = top; 
double r=0 ; 
int l=0 ; 
Bid al ; 

while (index.next != null) { 
index = index.next; 

if (index.bidderid!=0) { 
al = allocation (index, Q) ; 
r+= al.qty*al.price; 

//value(index.bidderid,Q) ; 

} 

} 

return r; 

// if (l==0) return 0; 

/ / else return r -= (1-1) *value(Data.NOBODY, Q) ; 

} 



} 

/ / substituted 8 float to double 



Figure 13(c) 
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<?xml version "1.0° encoding ="UTF-8" ?> 

- <GenericAuctionAgent 

context="http^/HOSTNAME:HnP_PORT/bx/RESOURCE NAME°> 
<Playertdentity name="RESOURCE_USER" passwd="RESOURCEJ>ASSWD° 
ipaddress="127.0.0.1" ne\mas\<="255.255.255.25S' l> 
-<PSPBidList> 

<param name= 'randomduration" value="faise° /> 
<param name= "duration" value="60000" /> 
<param name="mustconv" value-'true" /> 
<param name="bidfee" value="0.01 D l> 
<param name='capacity" value"20000.0" l> 
</PSPBidList> 

<UnixCryptAuthenticator passwdfile="MERKATO_HOME/accounts/passwd" /> 

- <LinearValutaion> 

<parameter name="qmax° value=°QMAX_VAL" label*"QMAXJJNHS n /> 
<parameter name="vmax" value^MAX.VAL" label=*VMAXUNlTS n /> 
</LinearValuatiori> 

<param name- accountingDriverClass' 1 

value="ihn .merkato J\ccountManager" l> 
<param name="accountFile° 

value="http://H0STNAME:HTTP_P0RT/bx/dbstub'7> 
<param name="hwDriverClass" vaiue="RESOURCE_DRIVER.CLASS" /> 
<param name="hwDevice" value='*RESOURCEJDRrVERJNIT" /> 
<param name-'maxNBids" value-iOO" /> 
<param name-Verbose' value="true" /> 
<param name="rememberlds" value-false" l> 
<param name-'clientTimeout" value="60000" /> 
<param name- 'serverTimeouf value- '30000" /> 
<param name="pause" value="5000" /> 
<param name="detailedlog n value-'true" /> 
parameter name="maxBidFee" value="1.0" label="$"/> 
parameter name= n maxAccountBalance" value="10000.0" label="$" l> 
</GenericAuctionAgent> 



Figure 14 
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Wizard - Bid Widow 



Applet window. Do not close while Merkato playep 
running on this computer. 



r Budget — | 
$ month 



0.0 




Time Left— i 
sec 



r- Allocation 

Kbps $/month 



ncy -, r Quantity — i rTime 




0.0 



0.0 



Kbpsr^; 



month 



Unload 



Account 



Stop 
Bidding 



Srtow 
auction 
graph 

Countdown timer for 
current auction. 
Reset whenever a 
new bid is received. 




Uploads agent 
to garage where 
it can continue 
bidding and exits 



Display 
account 
summary 
screen 



"Budget" is used to 
calculate price per unit 
bandwidth bid during 
auction. 



This is the last price offered 
with quantity desired bid 
(changes often so need to 
"Refresh"). 

Amount of bandwidth and 
extended price allocated to 
this agent during the last 
auction round 

Select the units for the 
display. Previously entered 
values will scale to the 
new units 



Display help. When checked, 
mouse-button presses bring up 
help rather than performing 
function 



"Stop" means to stop bidding. This bidding agent will not be charged and they will be 
placed in the shared best-effort queue. 

"Upload" uploads the configuration to the garaged agent. Not that this will change 
some advanced settings to those assumed by this simple valuation and strategy 
model. 

This simple budget-based valuation model has the bidding agent attempt to get as 

much bandwidth as possible without exceeding the budget number. 

The strategy is based on the formula: price-per-unit-bandwidth * bandwidth- 

allocated=total-price-paid 

Where the total-price-paid ("budget") is held constant, and the other two variables 
allowed to be altered. 

Following this strategy, the bidder will first attempt to get all the bandwidth the seller is 
offering for their budgeted amount, which works out to the lowest possible price-per- 
unit-bandwidth. If unsuccessful, the bidding agent gradually increases the the offered 
price-per-unit-bandwidth and decreases the desired amount of bandwidth, until they 
successfully win an allocation. 

If all bidders follow this valuation model, they will each get a bandwidth allocation that 
is the same proportion to total bandwidth as their budget is to the combined budgets 
of all bidders. 

From the "Help" screen" 

• Press Start to tell your r-v.jent io start bidding for you. 

• Press Stop to tell your - n r. o stop 



: fgvr* 15(c) 
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"Resource Agent" Subscreen 

Selection screen for resource for which you are bidding 



{3demo-merkatomuctionmuyer/produc1/demo/#7S LDlIx] 



File View Help 



Valid bidjfvugfyitedlkjotnuigoimyn876bu6jytfgo8ntb7o6r6b 
ALLOC 2.14 Mbps @ 156 12 oizdng;odrk 
netbpsmpoxfmpfotmhnpxnmcypnm 



-Resource Agent - 



dzpgimzoir goeimrt woueirnc[AOmd 



Java Applet Window 



Pull-down menu 
allows you to 
determine which 
resource you would 
like to bid on. 



Figure 15(f) 
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